src/pages/groupSearch/GroupSearch.tsx (2)

44-48: fetchRecentSearches가 useEffect 의존성 배열에 누락되었습니다.

Line 41의 마운트 effect에는 eslint-disable 주석이 있지만, 이 effect(Line 44-48)에서는 fetchRecentSearches를 호출하면서 의존성 배열에 포함하지 않았습니다. useCallback으로 감싸져 있어 현재는 안정적인 참조이지만, fetchRecentSearches를 의존성에 추가하는 것이 좋습니다.

♻️ 수정 제안

   useEffect(() => {
     if (searchStatus === 'idle') {
       fetchRecentSearches();
     }
-  }, [searchStatus]);
+  }, [searchStatus, fetchRecentSearches]);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/pages/groupSearch/GroupSearch.tsx` around lines 44 - 48, The effect that
calls fetchRecentSearches when searchStatus === 'idle' is missing
fetchRecentSearches from its dependency array; update the useEffect to include
fetchRecentSearches (i.e., useEffect(..., [searchStatus, fetchRecentSearches]))
and ensure the fetchRecentSearches function is memoized with useCallback (or
remains so) to provide a stable reference; also remove any eslint-disable
comment masking this dependency if present so the linter can validate the
dependency list.

---

139-141: reloadKey에 searchStatus가 포함되어 있어 불필요한 재요청이 발생할 수 있습니다.

searchStatus가 'searching' → 'searched'로 변경될 때 queryTerm도 함께 변경되면, reloadKey의 searchStatus와 queryTerm 두 값이 모두 바뀌면서 effect가 두 번 트리거될 수 있습니다. 또한 searchStatus가 isFinalized 파라미터에도 영향을 주므로, reloadKey에서 searchStatus를 제거하면 실제 검색 파라미터 변화에만 반응하도록 할 수 있습니다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/pages/groupSearch/GroupSearch.tsx` around lines 139 - 141, The reloadKey
currently includes searchStatus which causes redundant reloads when status flips
(e.g., 'searching'→'searched'); update the invocation of useInifinieScroll by
removing searchStatus from the reloadKey (keep
reloadKey=`${queryTerm}-${selectedFilter}-${category}`) so the effect only
reacts to actual search parameters, but leave the enabled logic (enabled:
searchStatus !== 'idle' && (searchStatus === 'searched' || !!queryTerm)) and any
isFinalized handling unchanged.

src/pages/mypage/SavePage.tsx (1)

118-191: 렌더링 로직의 중첩 삼항 연산자가 깊습니다.

showInitialLoading ? (...) : activeTab === '피드' ? (...) : savedBooks.items.length > 0 ? (...) : (...) 처럼 4단계 깊이의 삼항 연산자 체인은 가독성을 떨어뜨립니다. 각 조건별 렌더링을 별도 컴포넌트나 함수로 추출하면 유지보수성이 개선될 수 있습니다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/pages/mypage/SavePage.tsx` around lines 118 - 191, The JSX uses a deeply
nested ternary (showInitialLoading ? ... : activeTab === '피드' ? ... :
savedBooks.items.length > 0 ? ... : ...) which hurts readability; refactor by
extracting each branch into small components or functions (e.g.,
LoadingSkeletons using FeedPostSkeleton and BookSkeletonItem, SavedFeedList
rendering savedFeeds.items with FeedPost and handleFeedSaveToggle, and
SavedBookList rendering savedBooks.items with Cover, BookInfo and
handleSaveToggle) and replace the ternary chain in SavePage's render with a
clear conditional (if/switch or direct component returns) that returns
LoadingSkeletons, SavedFeedList, SavedBookList, or EmptyState accordingly;
ensure you keep sentinelRef, isLoadingMore, keys (feed.feedId, book.bookId) and
props like isLast/isMyFeed when moving logic.

src/pages/memory/Memory.tsx (2)

207-221: 서버 필터링과 클라이언트 필터링이 중복됩니다.

fetchPage에서 이미 isOverview, pageStart, pageEnd, isPageFilter 파라미터를 API에 전달하여 서버 측에서 필터링하고 있습니다(Lines 114-120). 그런데 filteredRecords(Lines 207-221)에서 동일한 조건으로 다시 클라이언트 필터링을 수행하고 있습니다. 서버 응답이 이미 필터링된 데이터를 반환한다면 이 메모이제이션은 불필요한 연산입니다.

서버 필터링만으로 충분하다면 filteredRecords를 제거하고 recordsList.items를 직접 사용하는 것을 고려해주세요.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/pages/memory/Memory.tsx` around lines 207 - 221, The client-side
filtering in the useMemo named filteredRecords duplicates server-side filtering
done in fetchPage (parameters isOverview, pageStart, pageEnd, isPageFilter);
remove filteredRecords and replace its usages with recordsList.items (or change
the memo to simply return recordsList.items) so we rely on server-filtered
results; ensure any references to activeFilter/selectedPageRange that expected
client-side filtering are updated to trigger fetchPage instead and that UI logic
still behaves correctly.

---

143-151: Axios 에러 타입 체크가 취약합니다.

덕 타이핑으로 'response' in error를 확인하는 대신 axios의 isAxiosError 유틸리티나 instanceof AxiosError를 사용하면 타입 안전성이 향상됩니다. 관련 코드 스니펫(getRoomPlaying.ts)에서도 instanceof AxiosError를 사용하고 있습니다.

♻️ 수정 제안

+      import { AxiosError } from 'axios';
       // ...
       } catch (error) {
-        if (error && typeof error === 'object' && 'response' in error) {
-          const axiosError = error as { response?: { data?: { code?: number } } };
-          if (axiosError.response?.data?.code === 40002) {
+        if (error instanceof AxiosError && error.response?.data?.code === 40002) {
             setActiveFilter(null);
             throw new Error('독서 진행률이 80% 이상이어야 총평을 볼 수 있습니다.');
-          }
         }
         throw new Error('기록을 불러오는 중 오류가 발생했습니다.');
       }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/pages/memory/Memory.tsx` around lines 143 - 151, Replace the duck-typing
error check in the catch block of Memory.tsx with axios' type-safe check: import
and use axios.isAxiosError (or AxiosError instanceof) to determine if the thrown
error is an AxiosError, then inspect axiosError.response?.data?.code === 40002
and call setActiveFilter(null) and rethrow the specific 80% message; otherwise
rethrow the generic "기록을 불러오는 중 오류가 발생했습니다." error—update the catch branch that
currently uses "'response' in error" and the axiosError type assertion to use
the axios utility or AxiosError type for proper type safety.

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled

You can enable these sources in your CodeRabbit configuration.

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled

You can enable these sources in your CodeRabbit configuration.

src/pages/feed/Feed.tsx (1)

112-119: TotalFeed 래핑 Fragment는 제거해도 됩니다.

현재 구간의 <>...</>는 단일 컴포넌트만 감싸고 있어 기능상 필요하지 않습니다. JSX 깊이를 줄이기 위해 제거를 권장합니다.

간단한 정리 diff

-          {activeTab === '피드' ? (
-            <>
-              <TotalFeed
-                showHeader={true}
-                posts={totalFeed.items}
-                isTotalFeed={true}
-                isLast={totalFeed.isLast}
-              />
-            </>
-          ) : (
+          {activeTab === '피드' ? (
+            <TotalFeed
+              showHeader={true}
+              posts={totalFeed.items}
+              isTotalFeed={true}
+              isLast={totalFeed.isLast}
+            />
+          ) : (

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/pages/feed/Feed.tsx` around lines 112 - 119, Remove the unnecessary React
fragment wrapping the single TotalFeed component in Feed.tsx: delete the
surrounding <> and </> around the TotalFeed JSX so that TotalFeed is rendered
directly (keep props: showHeader, posts, isTotalFeed, isLast intact); verify no
other siblings rely on that fragment and that JSX still compiles.

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled

You can enable these sources in your CodeRabbit configuration.